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Abst ract 

With the developnant of high-level languages for new canputer architectures corns the 
need for appropriate debugging tools as will. One mthodfor meting this needwuldbe 
to develop fromscratch, a symolic debugger wththe introduction of eachnewlanguage 
inplenantati on for any given architecture. This, hovever, seem to require unnecessary 
duplication of effort anting developers, (onpil at ion technology has alleviated s ana du- 
plication of effort in the developnant of conpilers. (an sinhlar ideas aid in the efficient 
developnant of symolic debuggers as veil? 

Mygen explores the possibility of naking debugger developnant effiient byinffuencing 
the language and architecture developnant processes. Mygen is a "debugger generation 
systero" built upon the i dea that symolic debuggers can be cEvidedintothree conpanents: 
a set of source language interface routines, a set of nachine architecture interface routines, 
and a language- independent and architecture- independent debugger skeleton. Mygen then 
exploits this nodularity First, Mygen precisely defines as veil as houses the language- 
independent and architecture- independent debugger skeleton. Second, Mygen defines the 
protocol for interface interaction amng source language developers, nachine architecture 
developers, and the general -purpose debugger skeleton. Enally, Mygen provi des afrana- 
wxkinwich the resident debugger skeleton is autcmti call y developed into a stand alone 
symolic debugger; the resulting debugger is tailoredtothe sped fie provisions of aparticular 
language group and a particular architecture group 
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Chapter 1 



Int r oduct i on 



Kcent years have seenasurge of newconputer architectures as industry andacademawjrk 
to devel op faster processi ng pover . W:h the prectaihnance of hi ghr 1 evel programing over 
mchi ne- level programimg as veil, the needfor debugging tools that use source language 
nanas andnotations has increased 1 Mch effort has been giventoaut orating the phases 

of conpiler wi ting in order to sinplify highrlevel language iipLemntationfor these new 
architectures. Srilar efforts at autonat ion have not, unfortunately, been given to the 
production of debuggers. 

This lack of autonationindebugger prciductioncanprove expensive interna of engineer - 
inghours, and thus nmetary costs, requiredfor developnant. Earlyoninthe developnant 
of anexperimntal conputer systen^alowlevel debugger is needed to evaluate vhether the 
systems weiring correctly. Mter the newconputer systems running, each newhigh- level 
language wittenfor the systemrequires a corresponding high- level debugger because users 
vant to debug interna of the synbols and constructs of the source language. Qk nathod 
for meting these debugging needs vouldbe to develop fromscratcha new debugger for 
each new architecture and for each new language inplenanted for a given architecture. 
Ihfortunately, wi ting debuggers is not only tedious but also tina consunfang. 



1 The terms "high-level debugging," "source- level debugging," and "synbolic debugging" are used inter- 
changeably to man debugging of program in terns of their source-level nams and constructs. 
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CHAPTER 1. INTRODUCTION 13 

Asimlar proUemccaircatfedcorpler developers about fifteen years ago. Gjrplation 
technology bas since then focused on reducing duplication of effort for various phases of 
corpler imiemntati on vith considerable success. Met notably, parser generators [Joh.75, 
MRT9, ASIB6, ET88], such as yacc[Joh75], and scanner generators, such as le:x[ASlj86, 
ET88] , haveessentiallyelirinatedthe mnual creation of parsers and scanners, respectively, 
less knovnbut also imwrtant have been efforts at automating the developrHnt of code 
generators [GGT8, M79, Br82, D($2] and even entire corplersffflt +82, R»s82, If 90, 

Sto77, Sch88] . Mygen explores the possibility of applying simlar ideas of automtionto 
debugger developmnt. 

1.1 Project Overview 

This thesis explores a novel approach to providing source- level debugging support through 
the developnant of a "debugger generation system" In general, an all-purpose debugger 
generation systemright be a tool that takes as input a source language description and a 
mchine architecture description, 2 and produces as output a fully functional, standalone, 
language- dependent debugger for the specified architecture. Egure 1-1 depicts suchasys- 
tem 

Adebugger produced by such a generation systemconsists of a core debugger skeleton 
(SHL) provided by the generator, a source language interface (SEE) created by the gener- 
ator fromthe source language input, and a mchine architecture interface (ML) created 
by the generator fromthe mchine architecture input. Egure 1-2 depicts the corponents 
of such a generated debugger. 

The debugger generation systemdesigned in this project is called Mygen 3 Mygen 

differs fromthe described all-purpose generation systemin term of vhat informtionis 
conveyed fromeach of the source language and mchine architecture developers to the 



2 Details about the term "source language" and "mchine architecture" can be found in Section 4. 2. 

3 The nans "Maygen" originatedf romanini ti al project goal of generating various synbolic debuggers for 
one specific target architecture, the Myfly[Eav92]. The project later evolved to enconpass various target 
architectures as well, though the nans Mygen renained. 
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generation system In the all-purpose system input consists of source language and target 
architecture descriptions that are then used by the generator to automtically create the 
needed interface routines. In the Mygen system the mxiral set of routines comprising 
eachinterface is fully specified by Mygen to the users of the generation system the input 
fromthe users contains informtionthat conveys toMygenvtichof the defined interface 
routines are available. Qice the available interface routines are knovn, the Mygensystem 
deterrines vhat additional conponents (parts of the SHL) are necessary to provide overall 
debugger functionality as veil as to promt e the smoth interaction of the tvo interfaces 
described above. The Mygensystenfranawrkmintains the debugger skeleton, interprets 
the inputs, and perf arm the necessary infarnati on processing to create a standalone, 
language- dependent and architecture- dependent debugger. 

Bgure 1-3 depicts the interrelationship arnng users of the Mygensystem Mygen 
users can be classified into one of tvo groups. "Ihase I" users vork vith the Mygen 
systemat debugger generationtim, vfcile "Ihase II" users vork vith generated debuggers 
at debugger runtim. 

Aprototype of the Mygen systemhas been developed and tvo test sets have been run 
to demnstrate the viability of such a system The test sets include a declarative Irolog- 
like source language running on a target virtual nachineennlatar andaninperative source 
language running on a target parallel, mssage-passirgdstributedmnsry architecture. 

1.2 Thesis Organization 

The reminder of this thesis describes the advantages and disadvantages of related vork, 
explains vhythe Mygen generated debugger is amre feasible approach, and presents the 
design, inpLemntation, evaluation, andachievemnts of the Mygensystem 

Chapter 2 begins by briefiy exarining previous research efforts at providing debugging 
support for ml ti pie languages. 

Chapter 3 presents the features of the canonical Mygen debugger in corner i son and 
in contrast to existing debuggers. 
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Chapter 4 then describes the Mygen systemdesign, including the source language and 
mchine architecture interface protocols, the core debugger skeleton, and the generation 
f ramvark used to create debuggers. 

Chapter 5 elaborates upon the prototype of the Mygen systemt hat was developed, as 
veil as provides sona of the mre interesting iipLenantati on issues involved. 

Chapter 6 then discusses the test cases used to evaluate both the capabilities and the 
effectiveness of the generationsystemprototype. 

Enally, Chapter 7 surnarizes the Mygen project, presents the author's conclusions, 
and speculates upon possible directions for further research in the area of debugger gener- 
ation 



Cha p t e r 2 



Rel at ed Work 



lie idea of debugger generation, althoughno such systems knovnto exist or toever have 
been desi gned, vas proposed by Johns on[ Joh78] in 1978. Wle Johnson's ovn focus vas on 
providing a nnl ti lingual tool for debugging, he connisntedthat a debugger generati on sys- 
temcoul d possi hi y be an al ternati ve approach to provi di ng source- 1 evel debuggi ng support 
for mLtipLe languages. 

Ebspite the lack of previous vork on debugger generation, tvo related areas of research 
have provided scm insight for the Mygen project. Specifically, the areas of nnLti lingual 
debugging and language- independent debugging also try to provide debugging support for 
nnltiple languages. 

2. 1 Mil t i 1 i ngual Etebuggi ng 

MLtilingual debugging is a debugging style that perimts the debugging of softvareinvhich 
conponents have been witten in mre than one source language [Joh82] . MLtilingual 
debugging is useful to consider because of sona issues that are sirilar to those of debugger 
generation. Specifically, the needtodistinguishbetveenlanguage-dependent andlanguage- 
independent conponents of debuggers pertains to both 

Ttoexanples of mltilingual debuggers are WQHIfRa83] and SWL[Gff83]. 
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CHAPTER 2. RELATED WORK 19 

MSQlHJGis the MKll Debugger developedat Dgital Bjipmnt Ghrparation lor a 
particular set of supported source languages, MKUBUGunder stands: howsyribol nanas 
are corposedinthe language, howLanguage egressions are interpreted, howandvhentype 
conversions are done in the language, howvalues in the language are displayed, and how 
the language scope rules vork Athough MSQlhUGunder stands this infarnationfar a 
defined set of languages, it operates according to the rules of only one language at a tim. 
MKQHJG supports the folloving languages: asserHy, Efftran, Hiss, Ifasic, Ghbol, 
lascal, andHyl. 

SWis a source- level debugger developed by Dita Gneral Ghrparation SW 
supports five highrlevel languages, each of vhich conform to an agreed upon "Goran 
Ghrpler Ghmonent Mthodology. " This mthodology defines a conran intermdiate 
language, procedure- calling sequence, and language runtimenvironmnt that rust be fol- 
lowed by each of the supported languages. The languages understood by SWare: Q 
Ghbol, Ehrtran77, lascal, andHyl. 

2. 2 Language-i ndependent Etebuggi ng 

Simlar to the idea of ml ti lingual debuggingis language- independent debugging. language- 
independent debugging refers to debugging techniques that are independent of any one 
particular source language [Joh82] . Adebugging systemthat has dealt specifically vith 
the issue of language- independence is the JMIE systen[iJoh77] . Johnson explains that 
a separate debuggLry laryux/s right be desirable. The debugging language created for 
the JMIE system called Dspel[ JohSl] , is designed to aid comnri cation betveen an 
interactive user andaruntim, syribolic debugging system 

2. 3 .Advantages and EL sadvant ages 

Indeed, these previous system present approaches to debugging that appear to accomo- 
date ml tiple languages. Such accomodation leads toinprovedecanonyof irpLemnta- 
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tiarias veil as increased ease in product naintenance. Inaddtion, these system offer a 
certainamunt of functional consistency to the debugger user. 

Infortunately, these system have several shortcomings. Erst, theyare unable to handle 
the peculiarities of any specific language; there is no extension nachanismvith vhich to 
cater to the needs of a given particular language. Second, the languages supported by each 
of the ml ti lingual debuggers are specified beforehand; to handle another language vould 
manhavingtorewite the debugger itself. These system are lirited to debugging not just 
a pre- defined set of languages, but mreover, only a pre- defined set of semntically sinhlar 
languages. 

Afurther fault lies inthe language- independent debugging systemas veil. Auser rust 
first learn a conpletely separate language, the debugging language, before even being able 
to start debugging a program Qice debugging can actually proceed, the user then needs 
to vcrry about the possibility of faulty ddmff,iy pnqpams in addition to faulty source 
program. 

Akmttedy, rnltilingual and language- independent debugging techniques offer sona 
gains over single- language debuggers. Nevertheless, the deficiencies in these debugging 
techniques are considerable. 



Cha p t e r 3 



Canonical Generated Debugger 



lie Mygen debugger tries tomintainthe desirable features of mi ti lingual and language- 
independent debuggers vhile also trying to inproveupon their shartcanhngs. This chapter 
begins by describing the features of the canonical Mygen generated debugger, proceeds to 
explainthe mti ration behind the chosen desi gn, and then denmstrates howthis designis 
able to offer mre than ml ti lingual and language- independent debuggers. 

3. 1 Qrervi ew 

The canonical Mygen debugger generally reserHes atypical single- language source-level 
debugger for a corp led language inthat it offers the "traditional"functionalitywth\hich 
users are accustomdto debugging program. The Mygen debugger debugs corp led code 
that has not been optimzed. It is also expected that the user starts up the Mygen de- 
bugger and then runs a programunder debugger control. The mximl set of fundamntal 
debugging facilities that are supported 1 by a Mygen debugger include: starting, stopping, 
single- stepping, and continuing an execution; loading a fie; resetting the nachine; setting, 
clearing, and listing nachine- level as veil as source-level breakpoints; activating and sus- 



1 Each of the supported facilities is only available upon satisfaction of specific conditions. See Chapter 4 
for details. 
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IbLe 3. 1: Canoni cal Maygen Debugger Functi onali ty 



Start execution 

Stop execution 

(out i nue executi on 

Single- step execution (fell owng calls) 

Single-step execution (not foil owng calls) 

Ioadafile 

Kset the mchine 

Set, clear, list mchine-level breakpoints 

Set, clear, list source-level breakpoints 

Ativate breakpoints 

Suspend breakpoints 

Dsplay and set variable values 

Dsplay register values 

Tace anduntrace variables 

Tace and untrace procedures 

list traced variables 

list traced procedures 

list user prograrriabels andsyrhols 

Showcurrent source line 

Bint inforrati on about debugger status 

Dsplay list of debugger cannands 

Kpeat previous connend 

Quit Bbugger 

(orient (ignored) 



pending breakpoints; displaying andsetting variable values andregister values; tracing and 
untracing variables and procedures; listing traced variables and procedures; indicating the 
current source line; displaying a list of debugger connands vith help inforrati on; repeat- 
ing the previous connand; quitting the debugging session; and adding a cannant. The 
Mygen debugger functionality is sumarizedin'Hie 3.1. 

liach connand' s avail ability depends uponits serantic correctness inthe context of the 
particular source language or rachine architecture involved, as veil as upon the support 
providedbyboththe source language andthe rachine architecture developers. Fjrexanple, 
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a debugger user shod diet be able to set logic variables in Prolog; thus, the cormandtoset 
the value of avariableis not mde available inageneratedlrolog debugger. In this narmer, 
each generated debugger is tailored specifically to the particular language and architecture 
in question 

In addition to the fundanantal debugging facilities, the Mygen debugger also has a 
mchanismfor incorporating extension carnands that are then fully available to the de- 
bugger user. Ibr exanpLe, the option to choose vhether an execution wll proceed in a 
breadth- first narmer or a depth- first narmer is not provi ded by the canonical Mygen de- 
bugger; hovever, this right be a desirable cormandto have inalrolog debugger. Alrolog 
systemdeveloper, then, can specify this option as an extension comand to the Mygen 
system, wich wll then add it to the set of ccmands available in the generated Prolog 
debugger. 

Extensi on comands can be specified and provided by the source language developer, 
the rachine architecture developer, or both Extensi on comands are of tvo general fla- 
vors. "Independent" extension comands are self- contained in that their functionality does 
not depend upon any routines that right not be available, e.g., fromeither the source Ian 
guage interface routine set or the rachine architecture interface routine set. "Dbpendent" 
extension comands, on the other hand, are not self- contained in that their functionality, 
and thus their availability to the debugger user, depends upon at least one of the routines 
fromeither the source language interface routine set or the rachine architecture interface 
routine set. 2 

Enally, the canonical Mygen debugger understands that not all rachines are uniproces- 
sors; the Mygen debugger understands that arachine ray have mre than one processing 
node. Insuchcases, the Mygen debugger operates onasingle node at atina. The debugger 
user has the ability to deterrine the total nurher of processing nodes present, deterrine 



2 E ther type of extensi on conrauid — i ndependent or dependent -e-an use routi nes expl i ci tl y provi ded by 
the debugger skeleton if desired. (See Chapter 4 for details. ) Since the availability of an extension comand 
does not hinge upon the availability of routines provided by the debugger skeleton (because the latter are 
al ways aval 1 abl e) , debugger skel eton routi nes do not pi ay a rol e i n the cl assi ficati on of extensi on conrauids 
into one of the tvo categories. 
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IbLe 3. 2: Ad d i ti onal Maygen Debugger Functi onali ty for Mu l t i proces 



Bsplaynurher of nodes present and available 

Showcurrent node 

Swt ch to a di fferent node 

Change nuriier of nodes available 



the nuriier of nodes available, deternhne vhichnode is being debugged, swtchfromthe 
current node being debugged to a different node, and change the nuriier of nodes available. 
Mygen's default node of executi on f or niti processors is that vhichis provided by the 
nacbd ne ar chi t ecture devel oper . Ifal e 3. 2 sumari zes the addi ti onal debugger functi onal i ty 
provided by Mygenfor ml ti processor architectures. 



3.2 Efesign 

3.2. 1 Eebuggi ng Unopti m zed Corrpi 1 ed Code 

The canonical Mygen debugger vas developed to vork on unopti nhzed, conpiled code 
rather than on opt i nhzed or interpreted code. Athough using aninterpreter as the base of a 
debugger right be beneficial because of howvell it supports interactive debugging[Mk91] , 
the approach is mre conplicated. In addition to a debugger skeleton, the generation 
systemvoiid need to naintain an interpreter skeleton as veil, lis interpreter skele- 
ton either vould need to interpret a broad class of source languages, vhich is currently 
i nf easi hi e[ Joh77] , or voul d need to be devel oped ty the generati on systerri nto a 1 anguage- 
dependent, architecture- dependent interpreter. The generati on of such an interpreter right 
itself be an interesting research prohlen^ but is tangential to the issue of debugger genera- 
tion. 

Jurthermre, Toi si [ To82] points out that interpreted code nay run differently than 
carp led code; thus, a debugger based upon aninterpreter naynot illurinate the problem 
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area of the source code. In addition, a debugger based upon an interpreter right suffer 
f romsi gni ficantl y decreased executi on speecf Klvf 5] . 

likewise, the issue of debugging opt irized code is also tangential to the pri nary concern 
cf howtoautonaticallycreateasyriiolic debugger. 3 Thus, the canonical Mygen debugger 

expects that the code a user loads and therefore wants to debug is unoptirized. Qice such 
code has been deter rimed to be correct, then the user can explore perfarnance issues. 

3. 2. 2 Provi di ng Tai 1 ored, Tradi ti onal Functi onal i ty 

The canonical Mygen debugger offers a variety of traditional debugging carnands to the 
user. Such a desi gn was chosen not only because users are mre accustomdto this nathod 
of debugging and thus can have less startup tina learning howto use a Mygen debugger, 
but also because users wouldbe provi dedvith the essentials of aruntinadebuggingsystern 
which are the ability to set breakpoints and exarime values within the programbeing 
debugged[B-o79, JohSl] . 

Sana traditional debugging cornands, such as starting an execution, nake sense for 
essentially all languages. The relevance of sona other connands, however, are not nec- 
essarily i mediately apparent. Ibr exanple, setting a breakpoint nakes perfect sense in 
a language such as Car lascal; but, what does it man to set a breakpoint in Irolog? 
It right, for exanple, man the ability to tenporarily stop execution at any of the four 
ports of the ml ti ported box nuclei for Irolog executi on[ S\#0] . Aiother exanple is the 
tracing of variables. This right nake good sense i n an inperative language, but what does 
it man in a declarative one? Ai exanple of howthe tracing of variables could be used 
in a declarative language is tofollowclauses that natch (are true) for a particular search 
In cases such as the two described, it is left up to the language developer or architecture 
developer to decide in what narmer each supported traditional debuggingconDandcanbe 
best exploited for debugging of the given language on the given architecture. 



See Section 7. 2. 2 for mire details. 
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3. 2. 3 Support i ng Ext ens i on Cbimnnds 

Akittedy, not all of the trad ti anal debugging cannands are necessarily appli cable far all 
source languages or all mcbdne architectures. Kr this reason, the Mygen debugger right 
only provide a subset of the traditional comHnds, depending on the specific language and 
architecture in question. That is, the Mygen debugger is specifically designedtobe capable 
of having a carmndset tailored to the target language and architecture. 

This tailoring of the Mygen debugger' s connandset goes beyond si mly deleting ir- 
relevant or inapplicable traditional debugging cannands. Suchasystemyoddbe not only 
tooli riiting for the extrenaly unconventional target language and/or architecture, but also 
not good enough for amre conventional but slightly different target language and/or ar- 
chitecture. AxorcEngly, the Mygen debugger is designed to support extension cannands. 
The extensionconDands enable language and architecture developers to extend the basic 
comandset of a Mygen debugger to include any additionally desired functionality that 
is potentially highly- sped fie for that particular language or architecture. 

3. 2. 4 Supporti ng Mil ti processors 

Athough the target architecture for Mygen right be a parallel one, the focus of this 
proj ect i s on devel opi ng a mthod for gsmratin/ debuggers rather than on deterrini ng the 
best ye$ to irfLemt ajprdld debugger. Thus, Mygen debuggers have been designed to 
deal only vith si nple notions of parallel ism. such as knoving about the existence of mil ti pie 
processing nodes. AMygen debugger operates on one processing node at a tim and can 
swtchfrornone node to another upon the user's request. These capabilities allowfor mre 
naaningful debugging anarnltiprocessar than possible frorra debugger vithabsdutelyno 
knowledge of rnlti pie nodes. Mygen generated debuggers do not, hovever, acklress mre 
comiex parallelismissues, such as the mo taring of interprocess comnni cation Such 
issues, alt hough potentially beneficial, voddtend to detract fromthe pri nary concern of 
the project. 
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3.3 .Advantages 

The mre obvious advantages of using Mygen debuggers over traditional, single- language 
debuggers are sinhlar to the advantages attributed to the use of mltilingual or language- 
independent debugging techniques. Erst, Mygen debuggers still present a certain degree 
of functional consistency to the debugger user, resulting in less learning overhead. Second, 
Mygen debuggers are cheap to buildsince they require little vork on the part of language 
developers and architecture developers carroared to the effort needed to create debuggers 
fromscratch. Enally, Maintenance is si rplified because the driving engine of the debugger 
is sinhlar fromone Mygen debugger to the next. 

Wle Mygen debuggers share the advantages of rnltilingual and language- independent 
debugging system over traditional, single- language debuggers, Mygen debuggers addi- 
tionally conpens ate for the deficiencies inherent in rnltilingual and language- independent 
system. Mygen debuggers are flexible; they can be tailored to the specific needs and 
peculiarities of different languages and architectures. This flexibility corns in part from 
the selective availability of the supported debugging routines. Mre inportantly, though, 
this flexibility corns fromthe systems allovance of and support for extension comiands. 
These features taken together result in a systemcapahle of handling senantically differ- 
ent languages. Effthermre, Mygen debuggers can be generated for mre than just a 
pre-defined, limtedset of languages. 

Hwis it that the Mygen debugger can be so flexible? The ansver lies inthe fact that 
it is a generated debugger, that it is generated according to the specifics of each particular 
language and each particular architecture. This is mde possible through the Mygen 
generati on system 



Cha p t e r 4 



Gener at i on Sys t em Etes i gn 



4. 1 Qrervi ew 

lie Mygen systemconsists of three mjor comonents: a set of interface protocols, a 

debugger skeleton, and a generati on framvork lie protocols specify the exact nature of 

the interface routines that promte s mot hccomii cat ion between the debugger skeleton 

and the rest of the prcgramirngenvironmnt. 1 The routines that are available for a given 

debugger to be generated are conveyed by my of input files to the generati on framwrk 

The generati on framvork, housing the debugger skeleton, processes the input data and 

produces a standr alone, language- dependent and architecture- dependent debugger. 

Egure 4- 1 portrays the canponents of the Mygen syst errand howt hey are interrelated, 
vhile Egure 42 show the pieces of a Mygen generated debugger. 

The Mygen systemvas designed in this narmer in order to have the capability of 
producing a debugger that is flexible, interna of handling very different inputs, yet prac- 
tical, in terra of providing large savings to language and architecture developers. Snce 
interpreter- based debuggers have sona intrinsic problem, the debugging of corp led code 
vas chosenas the basis for Mygen. The decision to have a generati on systemat all evolved 



lr Lhe "rest of the programing environnsnt" refers to the "source language" and "nachine architecture." 
These are expl ained in detail in Section 4. 2. 
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Egure4-1: The Maygen Debugger Generati on System 
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Egure4-2: The Components of a Maygen Generated Debugger 



franthe knowl edge that non- generated debuggers, suchas nnlti lingual debuggers, lackthe 
flexibility needed to support an arH trary nurher of language system as well as to handle 
senadtically different language system. Qi the one hand, the generation aspect, tailoring 
ability, andextensionrHchanisrmf the Mygensystemnate canonical Mygen debuggers 
flexible. Qithe other hand, the core debugger skeletonalongwththe automtic processing 
of it into a generated debugger mke canonical Mygen debuggers practical. 

Aialternativenat hod that was considered for achievingthe dual goals of flexibility and 
practicality was to add debugging constructs to a source file in a preprocessing- type step 
Ireprocessors have the advantage that the corpler of the source language to be debugged 
need not be mcEfiecfBMS] . This mthod, hovever, seemdtobe extrenaly liritingin 
term of what debugging capabilities a debugger user would have, as well as interna of 
what languages and system could actually be handled effect iwely. 
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4.2 Interface Protocols 

Aiinportant aspect of developing the Mygen systemis deciding upon the interaction of 

the Mygen debugger wththe rest of the varld. Scm programing languages enplaythe 

notional anabstract nachine, or virtual nachine, wthvhich to serve conceptual 2 and/or 

inplemntational 3 purposes. ^Sfenthis is the case, the high level aspects of the abstraction 

could be exploited for the purposes of debugging. Ai exanple is the mcEficatianof the 

parts of the Irologboxmdel to support debugging[S\$0] . 

Conventional languages such as Cand Ibrtran do not really have abstract mchines 
wthvhich to visualize their execution. Eff exanple, ina Xiix systen[]M83] , an object 
file produced by the Cconpiler executes as just another process running under the Xiix 
operating system Conceptually, one right visualize that process having a certainamunt of 
namry allocated to it andhave auction of data and instructions residing in that namry, 
as veil as a "location counter "that indicates the current instruction being executed. Qearly, 
such a rental mdel of programexecuti on i s dowinear the level of the operating system 
and nachine architecture anvhichthe process is running. 

The Mygen systemadopts an intermcE ate position tovard debuggers that attenpts 
to take advantage of higher levels of abstraction vhen available, but that can be used for 
lover-level conventional program as veil. The MygensystemBeparates the souKepxgxmi 
fromthe evduticnemmmt. 

AxarcEngly, the tvo interfaces to the Mygen debugger are the source programand 
the evaluatianenviranmnt. The interface to the source language is fittingly referred to as 
the Source language Interface (SII). The interface to the evaluatianenviranmnt is less 
appropriately referred to as the Mchine Achitecture Interface (MI); this interface right 



2 As a conceptual technique, the abstract nachine allows a high level way t o t hi nk about the execution of 
aprogram This capabilityis especi ally useful when the programing language contains non-trivial control 
nschanisns such as Prolog's unification or Snobol ' s pattern iratcher. 

3 A an inpl ensnt at ion technique, the abstract nachine can serve as a specification that describes details 
of aparticular algorithrn such as aunifier or pattern iratcher, used to inpl ensnt thelanguage. In addition, 
the abstract nachine can serve as an inpl ensnt at ion prototype, as in the Lisp functions Eval and ^>ply, 
which define the conplete lisp eval uator injust afewlines of lisp code. 
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encanpass not only the mchine architecture, but also a runtim systen^ an operating 
systern an abstract mchine, or a conbi nation 

The interface protocols specify the exact nature of the routines that are used by the 
core debugger to interact vith the source programand the architecture. 4 Each interface 

protocol can be thought of as the set of routines that conprise the interaction between the 
core debugger and source program or between the core debugger and mchine architecture. 
The Source language Interface routines are provided by a language developer, vhile the 
Mchine Achitecture Interface routines are provided by a systemdeveloper. 

Ijachinterface consists of apprcodnatelyfifteenroutines; these translate to the supported 
functionality of a generated debugger. There exists anhniml subset of routines that are 
required of the Source language Interface and of the Mchine Achitecture Interface in 
order for a vor king debugger to be generated Whthe provision of this ririml subset, 
Mygen can automtically create a lowlevel debugger. Wth the provision of increasingly 
mre Source language Interface and Mchine Achitecture Interface routines, Mygen can 
create syrholic debuggers vith increasingly larger amunts of functionality. These sets of 
interface routines are experi rant ally derived 

TSie 4. 1 lists the routines constituting the Source language Interface as specified by 
the current Mygen design Srilarly, TSie 4. 2 lists the routines contained in the Mchine 
Achitecture Interface as specified by the current Mygen design 

The interface protocols not only specify the routines that should be provided, but also 
the f ormt i n vhi ch such i nf ormti on i s conveyed to the generati on f ramverk The i nput 
to the generati on framvark consists of tvotext files, one for inf ormti on about the Source 
language Interface and the other for inf or rati on about the Mchine Achitecture Interface. 
The Source language Interface input file contains: ali sting of the Source language Interface 
routines vith specification of vhether or not each is available, the nana of the source 
language, the location and nana of a library containing the Source language Interface 



4 Henceforth, the "mchine architecture" and the "architecture" refer to the evaluation environnmt, 
except when specified otherwise. 
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IbLe 4. 1: Source Language Interface Ro u t i nes 



Initialize SH 

Mp procedure to object line 

Mp procedure beginning to object line 

Mp procedure ending to object line 

Tace procedure 

Mp source line to object line 

lead i n syritaol s 

Rint labels 

list procedures 

ftint syrhcls 

Dsplay text of current source line 

Tit race procedure 

ftocess initial debugger argumnts 

Rint SII infornation 



"Hie 4. 2: Ma chine Ar chi tecture Interface Ro u t i nes 



Initialize MI 

Is progranioaded? 

Install mchine breakpoint 

Continue program 

Xiinstall mchine breakpoint 

Set mchine breakpoint on a procedure 

Gear mchine breakpoint on a procedure 

lead i n program 

Rint register contents 

Rm program 

Step followng procedure calls 

Step not followng procedure calls 

Rset mchine 

Rocess initial debugger argunants 

Rint MI informtion 

Grange current processing node 

Orange nutiier of available nodes 
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routines, andinfornat ion about eachextensioncoriDanddesiredbythe language developer, 
lis extension cornand infarmti on includes the total nuriier of extension cornands 
supported by the language developer as veil as details about each extension cornand. 
These details include: the nana of the carnand, the declaration used to indicate it is an 
externally defined procedure, the invocation of the cornand vithits argunants, andalist 
of Source language Interface and Mchine Achitecture Interface routines upon vhich the 
proper functioning of the extension cornand depends. 5 

Snhlarly, the Mchine Achitecture Interface input file contains: a listing of the Mchine 
Achitecture Interface routines vith specification of vhether or not each is available, the 
nana of the architecture or abstract nachine, the locatianandnanaaf a library containing 
the Mchine Achitecture Interface routines, and infornati on about each extension com 
nand desi red by the mchi ne devel oper . The i nf ornati on for these extensi on cornands i s 
exactly analogous to that of the extension cornands for the Source language Interface. 
The Mchine Achitecture Interface input file additionally contains infornati on about how 
nany processing nodes are present as veil as hownany processing nodes are available in 
the target architecture. 

Aexanple of a Source language Interface input file tenplate, vhich can be filled in 
by a language developer, canbe found inApendix A Apendi xB contains an exanple of 
a Mchine Achitecture Interface input file tenplate. 

4.3 Debugger Skeleton 

The debugger skeleton consists of the conponents of a symolic debugger that have been 
determned to be language- independent and architecture- independent. These conponents 
have been grouped together toformthe ccreof a debugger, hence debugger dkddan, vhich 
the Mygen systemuses as the backbone vith vhich to create Mygen debuggers. 

The debugger skeleton can be thought of as providing the glue necessary for coherently 



5 For independent extension coraands, this list wl 1 be enpty. 
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sticking together the interface routines. Mre accurately, the debugger skeleton is several 
files of code, scm of vhich contribute directly (unchanged) to the code of a generated 
debugger, and som of vhi chare either supersets of or incoiplete fragnants of code that 
wll be nidified bythe generationframwjrkintocode that wll then be part of agenerated 
debugger. The final output files include amkefle wthwichthe user canmke the newy- 
generated debugger frarrits source code. 

Mre descriptively, the debugger skeleton consists of debugger conponents such as the 
debugger user interface, carmnd loop driver, andgrungy initializationandrBintenance 
routines, e.g., for keepi ng track of tracing. The debugger user interface can range froma 
sinple textual interface to aruchmre elaborate graphical user interface. This interface 
need only be witten once and then can be used for each subsequent Mygen debugger. 
Ai exanple of a grungy naintenance job is the breakpointing facility coordinating the 
setting (and checking for duplicates), clearing (and checking for validity), keeping track, 
listing, installing, uninstalling, activating, and suspending of nachine- level and source- level 
breakpoints. 

liach debugger cornand supported by the debugger skeletonis afliatedwth certain 
Source language Interface andMchine Achitecture Interface routines upon vhi chits func- 
tionality depends. Agiven, supported debugger connandis only available if the routines 
upon vhi chit depends are mde available bythe language and/or architecture developers. 
Ibr exanple, the connand that allows a debugger user to set a breakpoint on a source 
line depends upon one Mchine Achitecture Interface routine (install nachine breakpoint) 
and one Source language Interface routine (nap source line to object line). If either of 
these routines is not supported, then the source-level breakpoint setting connand is un- 
available in the subsequently generated debugger. The debugger connands supported by 
the debugger skeleton are identical to those previously described in "Hie 3.1. 

A nantioned previously, a few debugger skeleton routines are explicitly provided to 
aid Mygen syst emus ers. language or architecture developers can freely call these rou- 
tines fromvi thin either extension connands or Interface routines. The debugger skeleton 
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IbLe 4. 3: Debugger Skeleton Ro u t i nes Avai lable to Developers 



Install breakpoints 

Xiinstall breakpoints 

Check vhether breakpoint address already easts 

AM procedure to list of procedure breakpoints 

Itraw procedure fromlist of procedure breakpoints 

Aid mchine address to list of mchine breakpoints 

Itraw mchine address fromlist of mchine breakpoints 



routines supported in this mrmer are listed in "Hie 4.3. 



4.4 Generat i on Framework 



This section describes the overall framvark used by the Mygen systemto create afunc- 
tional debugger. This framwrk serves as the driving engine for accepting input infarm- 
ti on about the Source language and Mchine Achitecture Interfaces, for translating the 
input into vhich debugger carmnds vill be available, and for appropriately mdifying 
and appending the debugger skeleton to mke it a standr alone debugger. 

The generati on framwrk understands the formt of the input files and thus can read 
andinterpret the informtioninthe input. The generati on framvark also houses, or mre 
accurately, keeps track of , all the pieces of the debugger skeleton. The f ramvork knov« 
vhich pieces are to be left intact to becom part of a generated debugger as veil as vhich 
need to be either augnantedar chopped and spliced. 

The generati on framvark decides, based upon vhich Source language Interface and 
Mchine Achitecture Interface routines are knovntobe available, vhat conponents vill 
gointothe debugger to be generated and howthese conponents shouldbe put together to 
mke a vcrMngunit. The framvark processes the input infarmtiarito deternhne vhich 
debugger cannands vill comprise the carmndset of the debugger to be generated. These 
comandnams are thenincorparatedintothe "help list "avai lable to debugger users, vhile 
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the code that inplemnts these conniands are incorporated into the source code files that 
corple into the functional debugger. Enally, the generati on framwrk outputs all the 
necessary code files and a mkefile for the newMygen debugger. 

The framwrkis desi gned to perf azmat gsrmticntim all of the interpretation and 
processing necessary for a given debugger tobe generated. ly per f erring all input interpret- 
ing and processing during debugger generation, Mygen debuggers can aroid unnecessary 
runti m i neffii ency. 



Cha p t e r 5 



Prototype I npl ernent at i on 



lie Mygensysterrrlesignencomasses mre than does the prototype that has been i ml e- 
mntedthus far. This chapter describes the enviranmnt inwhichthe systerrwas developed 
and the scope of the prototype, as well as presents scm of the mre interesting inplemn 
tational details. 

5. 1 Qrervi ew 

The experimnt was carried out using the equipmnt and facilities of Hewlett Ik:kard 
Iabaratories. A single- processor workstation H9000/840 running IP IX 7. 0, Hewlett 
Ikdsard' s wersionof INX was usedfor the dewelopmnt of the debugger generationsystem 
The prototype Mygensystenis written in the Clanguage. 

The prototype generationsystenxansists of the Source language Interface andMchine 
Achitecture Interface protocols with routines defined and input file farnats specified, an 
iiplemnted subset of the desi gned debugger skeleton, and a f uncti anal generati on f ram- 
work that handles the existing debugger skeleton and inputs. 
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5.2 Mygen Debugger Features 

The canonical Mygen debugger of the prototype generation systemsupports mst of tbs 
functionality supported by that of the designed system These cannands are surmrized 
in "Hie 5.1. The cornHnds that are not stpported in this iiplemntationare listed in 
"Hie 5.2. Ai additional note is that the stpport for tracing and untracing of procedures 
is currently iiplemnted as the setting and clearing of breakpoints on procedure nanas. 
Taring of procedures coul d be mdemre elaborate by not onlyhreakingvhen a procedure 
is reached, but al so autonati call y displaying the values of the procedure's argunants upon 
invocati on and displaying any return value upon exit. 

A in the design, each debugging cornand's availability depends upon its semntic 
correctness in the context of the particular source language or nachine architecture in 
voiced, as veil as upon the support provided by both the source language and the nachine 
architecture developers. 

The prototype canonical Mygen debugger is able to support one of the tvo flavors 
of extension connHnds described in Section 3.1. Independent extension connHnds are 
currently incorporated in the prototype, vhereas dependent extension connands are not. 

Enally, the prototype Mygen debugger operates ona single node at atina, but under- 
stands that there right be mre than one processor inthe target architecture. Thus, vhen 
the target architecture has rnltiple nodes, the generated Mygen debugger allow the user 
to: deterrine the total nurher of nodes present, deterrine hownany nodes are available, 
find out vhichnode is being debugged, svitch bet veen nodes, and change the nurher of 
nodes available. This functionality is identical to that designed, vhichis sunniarizedin 
1hle3.2. 

5.3 Interface Protocol s 

The Source language Interface and Mchine Achitecture Interface are inplenanted as 
described in Section 4. 2, having the goal of separating the source programfromthe evalua- 
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1ible5.1: Debugger Functi onali ty Implemented In Prototype 



Start execution 

Stop execution 

(out i nue executi on 

Single- step execution (fell owng calls) 

Single-step execution (not foil owng calls) 

Ioadafile 

Ifeset the iHchine 

Set, clear, list mcline-level breakpoints 

Set, clear, list source-level breakpoints 

Ativate breakpoints 

Suspend breakpoints 

Dsplay register values 

Tace and untrace procedures 

list user prograrriabels andsyrhols 

Showcurrent source line 

Dint informti on about debugger status 

Dsplay list of debugger cannands 

Kpeat previous cannend 

Qdt Dbugger 

(orient (ignored) 



"Hie 5.2: De bugger Functi onali ty Not Implemented i n Prototype 



Dsplay and set variable values 
Tace and untrace variables 
list traced variables 
list traced procedures 
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tionenvironnant. The specified routines conpri sing the Source language Interface are the 
s ana as those listed in "Hie 4.1; likewse, the specified routines conpri sing the Mchine 
Achitecture Interface are the sam as those enunaratedin "Hie 4. 2. 

The input fie farnats, vhichthe Mygen prototype tises, are identical to those pre- 
scribed by the interface protocol design of Section 4.2. The sanple Source language In- 
terface input fie tenplate located in appendix Ais the actual input fie tenplate used for 
the prototype's language test cases. Srilarly, the sanple Mchine Achitecture Interface 
input fie tenplate located in appendix Bis the actual input fie tenplate used for the 
prototype's architecture test cases. 

5.4 Debugger Skeleton 

The prototype debugger skeleton consists of conponents of a syrholic debugger that are 
language- independent and architecture- independent, as designed Hnnever, the prototype 
debugger skeleton does not enconpass as inch basic supported functionality as does the 
desi gned debugger skeleton Aso, the debugger user interface is a purely textual one. 

The conmand loop driver is based upon a Clanguage switch statenant that swtches 
on the interactive user's typed connand This inpLenantation vas chosen for relative 
effiiency in carrying out the desired conmand and for ease in tailoring the appropriate 
code files to the inputs. 

The debugger skeleton consists of five files that contribute unchanged to a generated 
debugger's source code and six files that are nodi fied into files that are then directly part 
of a generated debugger' s source code. The files that contribute unchanged contain source 
code files that inplemnt breakpoints, essential debugger initializations and driver routines, 
and input /out put routines. These files also include header files that list Source language 
Interface, Mchine Achitecture Interface, and debugger skeletonroutines. 

The files that need to be nodi fied before becoring part of a generated debugger are 
the nakefie, "cases" file, "filer" file, extension conmand file, "nhs eel laneous" file, and 
"debugger help list" file. The "cases" file is a superset of the code needed to decide vhat 
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to performfor each comand ^Sfen the prerequisite routines are available for a given 
debugger connand, that comnaud wll be associated wth code that perform the actual 
connand; wien the prerequisite routines are not available, hovever, that connand wll 
be associated vi th code that relays to the user the unavailability of the invoked cannand. 
In addition, each connand i s accordingly added or not added to the debugger help list in 
the "debugger help list" file. Thus, vhenauser calls upahelplist of debugger camnands, 
those conniands that are not available, due to lack of suffiient support fromeither the 
language or architecture developer, wll not be includedinthelist. The "filler" fie is created 
by Mygento account for all of the Source language Interface and Mchine Aclitecture 
Interface routines that are not providedas inputs. Mygen creates "filler" routines to satisfy 
the conpiler's checks, knovingthat these dump routines wll not actually be called. The 
extension connand file is created by Mygento handle the calling of appropriate extension 
conmands upon a user's invocation of suchconmands. Enally, the "miscellaneous" file is 
created by Mygen to hold tvo architecture- dependent definitions as veil as routines for 
printing inf or rati on upon debugger startup and exit. 

5.5 Generat i on EtaiiEwork 

The prototype generatiariframvarkis as described in Section 4. 4. This generationfram- 
wrk understands the input file fornats, reads and interprets the input files, accordingly 
perform the actual nidifying of the debugger skeleton files described in the previous sec- 
tion, and outputs all necessary source code to create a new debugger. 
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Res ul t s 



lis chapter discusses the test cases used to evaluate the prototype generationsystera.and 
hence the Mygen systemdesign itself. 

6. 1 Qrervi ew 

The goal for choosing the test cases vas to select donains that are quite different in order 

to showthe flexibility that Mygen has in comparison to existing system for providing 

debugging support tomltiple prcgramnimgenvironmants. Eachtest set 1 is comprised of 

a source language that conform to the Source language Interface protocol (in term of 

interface routines and Mygen input file), and a machine architecture that conform to the 

Mchine Achitecture Interface protocol (interna of interface routines and Mygen input 

fie). 

Tk>suchtest sets have been run through the Mygen system The tvo source languages 
and their evaluation enviranmnts are: a declarative language, (Elj running on the (M 
virtual machine, andanimperativelanguage, Q running antheMynyparallel architecture. 
Bf generating a symbolic debugger for both a declarative language and an imperative 
language, Mygen demonstrates its ability to handle semanti call y- different languages. 



'A'test set" consists of both a source language "test case" and a mchine architecture "test case." 
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1ble6.1: SLI Routines Supported By OPAL 



Initialize SEE 

Mp procedure to object line 

Mp procedure begi nri ng to obj ect li ne 

lead i n synhol s 

Bint labels 

Bint synhol s 

Bint SII infornation 

Bocess initial debugger argunants 



6. 2 lest Cases 



6. 2. 1 OPAL and CM 



031) the Qegon Parallel logic language, is a Bolog-lite language developed at the 
Ihiversityof Gegon[(on90, (on91, (on92] . (EL is based on the AtyOt Bocess 
Mdel [ Kic90] , vhichis an abstract nadel for parallel logic program. The AtyGtBo- 
cess Mdel has an operational senantics defined by asynchronous objects that connnnicate 
entirely by nassages. 

031/ program are corp led into the instruction set of the 03i/Mchine, or OM. The 
(Ms a virtual nacMnesiniilar to the Wrenabstract nachine[W83] for standardBolog 
inplenantations. The difference is that the Q/frirtual nachine is designed for program 
that execute according to the AtyGtBocess Mdel on nonshared namry nil ti proces- 
sors. The version of the Q/Ivirtual nachine used for this test set runs on a uniprocessor 
INXvorkstation; it does not exploit ADor Gtparallelisrrinthis inpHenantation. 

The 031/ language test case supports eight out of the fourteen Source language In- 
terface routines specified by the Mygen prototype and provides no extension connands. 
The routines supported by 031/ are sunmarizedin "Hie 6.1, vhile those that are not 
supported are listedin'Hie 6.2. 

The Q/tdrtual nachine test case supports fifteen out of the s event eenMchine Achi- 
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1Ee6.2: SLI Routines Not Supported By OPAL 



Mp procedure ending to 


object line 


Tace procedure 




Mp source line to object line 


list procedures 




D splay text of current 


source line 


Tit race procedure 





tecture Interface routines specified by the Mygen prototype. AHtionally, the (Mtest 
case provides tvelve independent extension cormnds. 

The Q/Ivirtual mchine supports all of the Mchine Achitecture Interface routines 
except the tw> routines specific to mltiprocessars since the (Mnplemntationis for a 
uni processor. Ifales 6.3 and 6.4 sunnarize those routines supported and not supported, 
respectively, by the (Mirtual mchine. 

The extension comands provided by the (Mvirtual mchine provide the debugger 
user vith the capabilities to choose betveen: searching for all solutions or for just one 
solution, perfcrnhngabreadthrfirst or adepthrfirst search, executing in quiet mde or not, 
tracing processes or not during execution, tracing instructions or not during execution, and 
displaying registers synbolically or not. The extension comands also enable the user to 
print sections of object code, sections of the heap being used by the (Mvirtual mchine, 
nassage or process informtion, queue contents, andaprocess tree for the execution. These 
additional features are sumarized in TKie 6.5. Asanpie (MMchine Achitecture 
Interface input file can be found in ATpendix C 

The Mygen generation framvark accepted the input files of the described test set 
and produced a syribolic debugger for 031/ running on the Q/Ivirtual mchine. The 
debugger connands supported by the generated 031/ debugger are listedinTKie 6.6 

The 031/ Source language Interface input file and the CMMcHib Achitecture 
Interface input file vere tested to have varying nurhers of interface routines available to 
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1He6.3: MAI Routines Supported By OM 



Initialize MI 

Is program! ceded? 

Install mchine breakpoint 

Continue program 

Xiinstall mcHne breakpoint 

Set mcHne breakpoint on a procedure 

Gear mchine breakpoint on a procedure 

Ifead in program 

Irint register contents 

Hm program 

Step, followng procedure calls 

Step, not followng procedure calls 

Ifeset mchine 

Irint MI informtion 

ftocess initial debugger argunants 



1hle6.4: MAI Routines Not Supported By OM 



Change current processing node 
Change number of available nodes 
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"Hie 6.5: MAI Extensi on Commands Provi ded By OM 



Toggle all-solutions 


"Jiggle breadth first search 


Toggle quiet mde 


Toggle process trace 


Iggl e i nstructi oti trace 


Toggle synbolic register display 


ftint code 


ftint 


heap 


ftint 


iHssage infarmtion 


Wirt 


process iifariBtiori 


Wirt 


queue contents 


Wirt 


process tree 



Mygen The supportedfuixtionalityof eachresulting (Bi/debugger variant vas checked 
to ascertain that the debuggers changed accordingly. These generated (El/ debugger 
variants were then tested on a suite of (Bl/ program to verify their correctness. 



6.2.2 CandMyfly 

The language of the second test set is C| the famliar, inperative language developed by 
Rtchie[H88, B¥l] . Cis arelativelylowlevel, general - purpose programing language. 
Wle Cprovides datatypes and fundamntal cantrol-flowcanstructions such as looping 
and decision naking for single- threaded control flowf it does not provide built-in higher- 
level mchaiismsuchas input /output facilities or operations anconposite objects suchas 
lists and arrays. 

Gjnpiled C program are processed by the Myfly architecture[Div92] . The Myfly, 
developed at livtett lackard laboratories, serves as a back-end processor for a livtett 
lackard Series 800 vorkstatian. The Myfly is a scalable, general -purpose parallel pro- 
cessing architecture; it is adstributedmmrymchine wthccomni cation supported by 
nassage passing- 
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"Hie 6. 6: Functi onali ty of the Generated OPAL Debugger 



ftint help infarnati on 

Kpeat previous cranand 

Activate breakpoints 

Set breakpoint on object line 

Set procedure breakpoint (trace procedure) 

Continue frarnbreakpoint or step 

Eblete breakpoint on object line 

Eblete procedure breakpoint (untrace procedure) 

Kad in carp led user program 

D splay general registers 

ftint infarnati on about debugger stattis 

list breakpoints 

list user program! abels 

list user programsyrihiol s 

Qdt debugger 

Hm program 

Single step (followcalls) 

Single step (do not followcalls) 

Suspend br eakpoi nt s 

Ifeset nachine to startup state 

QraHdt (ignored) 

Bcecute an extensi on canaand: 

- Tggle all -solutions 

- Tggle breadth-first search 

- Tggle quiet mde 

- Tggle process trace 

- Tggle instruction trace 

- Tggle synbolic register display 

- ftint code 

- ftint heap 

- ftint nassage infarnati on 

- ftint process infarnati on 

- ftint queue contents 

- ftint process tree 
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IhLe 6. 7: SLI Routi nes Supported By C 



Initialize SEE 

Mp source line to object line 

Mp procedure to object line 

Mp procedure beginning to object line 

Mp procedure ending to object line 

list procedures 

lead i n syritaol s 

ftocess initial debugger argumnts 

Bint SII infornation 



1ble6. 8: SLI Routi nes Not Supported By C 



Tace procedure 

Thtrace procedure 

Bint labels 

Bint syrhols 

Bsplay text of current source line 



The Clanguage test case supports nine out of the fourteen Source language Interface 
routines specified by the Mygen prototype and provides no extension carnHnds. The 
routines supported by Care sunnarizedin "Hie 6.7, vhile those that are not supported 
are listedin'Hie 6.8. 

The Myfiy architecture test case supports sixteen out of the seventeen Mchine Achi- 
tecture Interface routi nes specified by the Mygenprototype. The Myfiy test case supports 
all of the Mchine Achitecture Interface routines except execution stepping that does not 
followprocedure calls. "Hies 6. 9 and 6. 10 sunniarize those routines supported and not 
supported, respectively, by the Myfiy test case. 

AH ti anally, the Myfiytest case provides three independent extensiaricoimnds that 
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IbLe 6. 9: MAI Routi nes Supported By Mayfly 



Initialize MI 

Is program! ceded? 

Install mchine breakpoint 

Continue program 

Step, followng procedure calls 

Xiinstall mchine breakpoint 

Set mchine breakpoint on a procedure 

Gear mchine breakpoint on a procedure 

Ifead in program 

Irint register contents 

Hm program 

Ifeset mchine 

ftocess initial debugger argumnts 

Irint Mt informtion 

Qiange current processing node 

Change nurher of available nodes 



"Hie 6. 10: MAI Routi ne Not Supported By Mayfly 



Step, not followng procedure calls 



give users the capability to select wichCHJof the current processing node to debug. Each 
Myfly processing node has tvoCHJ: the Mssage Irocessor (]\Jf) and the Execution Iro- 
cessor (EP). The MyfiyextensioncoriiHnds provide the debugger user viththe followng 
capabilities: to select the MP of the current node for debugging, to select the B?of the 
current node for debugging, and to determne vhichCHJis the current (being debugged) 
CHJof a given Myfly processing node. These additional features are sunnarizedinlSie 
6.11. 

The Mygen generation framvark accepted the input files of the described test set 
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IbLe 6. 11: MAI Extensi on Commands Provi ded By Mayfly 



Select ]\JPof current node 
Select B?of current node 
Ebternhne vhichQUis current (HJ 



and produced a C debugger f or the Myfly. The debugger cannands supported by the 
generated C debugger are listedin'Hle 6.12 

The C Source language Interface input file and the Myfly Mchine AcKtecture In- 
terface input file vere tested to have varying nurhers of interface routines available to 
Mygen. The resulting C debugger variants vere inspected to ensure that their set of 
supported functionality changed accordingly. A observedfor the CB5/(Mtest set, the 
supported functionality of eachresulting generated Cdebugger also correctly reflected the 
changed Mygen i nput s . 

Ehe tologistical cEffiulties, 2 the generated Cdebugger variants vere "tested" by closely 
vatchingthe cornands atterptedtobe vrittento the Myfly mnitor, the softvare that 
connects the Myfly architecture vithits front- end vorkstati on. Interfacing to this mnitor 
is the Myfly's debugger library. Nrmlly, any debugger for the Myfly calls basic routines 
fromthis debugger library. The debugger library routines, vfrichnormlly canmmicate 
di recti y vi th the Myfly vi a the mni tor program vere repl aced duri ng testi ng vi th verbose 
stubs. Atemtedcoimndwites to the mnitor f rorngener at ed Cdebugger variants vere 
ttencca^iaredviththeatteiptedconiiHndvTites of sirilar debugging comiands invoked 
froman existing, tested debugger for the Myfly. 



2 The Myfly architecture can onl y be used 1 ocally because its softvare currently does not support remite 
access. Mygen work, however, was conpleted 3000 riles fromthe residence of the Myfly. 
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"Hie 6. 12: Functi onali ty of the Generated C De bugger 



Print helpinformtion 

Kpeat previous canmand 

Activate breakpoints 

Set breakpoint on source line 

Set breakpoint on object line 

Set breakpoint at procedure beginning 

Set breakpoint at procedure exit 

Set procedure breakpoint (trace procedure) 

Continue fromhreakpoint or step 

Blete breakpoint on object line 

Blete breakpoint on source line 

Blete procedure breakpoint (untrace procedure) 

Kad in carp led user program 

D splay general registers 

Print informti on about debugger status 

list breakpoints 

list procedures 

list traced procedures 

Qdt debugger 

ftm program 

Single step (followcalls) 

Suspend br eakpoi nt s 

Ifeset mchine to startup state 

Conniant (ignored) 

Pxecute an extensi on cannHnd: 

- Select MP of current node 

- Select IP of current node 

- Bternhne \4ich(HJis current CPU 
Pxecute amltinode canniand: 

- Change processing nodes 

- Biter rime current nurher of nodes 

- Biter rime current node 
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Goncl us i ons 



lis chapter surmrizes the Mygen project, presents scm conclusions about debugger 
generation in general and the Mygen approach in specific, and suggests areas for further 
research 

7. 1 Suimary 

The abilitytoprovide debugging support for mi ti pie languages is aniiportant one because 
of today's demndfor high-level debuggers toacconpany high- level languages. 

"E© previous approaches that vere considered for providing debugging support for ml- 
tiple languages are mltilingual debugging and language- independent debugging These 
approaches right be feasible vhen the set of languages that the system support are se- 
mntically very sirilar. Such sirilarity, hovever, nay be mre rare in the future and is 
presently nonexistent for parallel languages. lince there has been a strong need to pur- 
sue other debugging mthods that are capable of supporting a semntically diverse set of 
languages. 

Mygen, the debugger generation systemdescri bed in this thesis, is precisely such a 
debugging mt hod. In light of the greater semntic cE versi ty amngst programing Ian 
guages, this systenis mre feasible than previous approaches to providing debugging sup- 
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part because of its ability to take into account different programming models. AkEti anally, 
generated debuggers exhibit a large degree of functional consistency, thus mhiimhzing the 
user's overhead in learning a new debugging systemfor eachnewlanguage. 

The Mygen systeimprovides for "qui ck and easy" creation of language- dependent de- 
buggers for the respective target architectures. Suchafeat is mde possible by the systeims 
imposition of interface protocols to be followed by language developers and architecture 
developers, provision of the glue necessary to not only smothly connect the tvointerfaces 
but also serve as the core debugging engine, and provi si on of the franawjrk that perform 
the actual gluing of the separate pieces. 

Mygen has been showito handle botha declarative language and an imperative lart 
guage vith reasonable results. The generated debuggers provided at least the nhniml 
functionality needed for useful debugging wthout inch additional effort on the part of lart 
guage and architecture developers. Mreover, the generated debuggers vere able to cater 
to the particular needs of eachlanguage and each architecture. Specifically, the generated 
(BSj debugger included several commands to provide for debugging features specific to 
Irolog-like languages, wile the generated Cdebugger included commands to provide for 
debugging features specific to multiprocessor architectures. 

Thus, the Mygen debugger generation systemis a viable approach to providing de- 
bugging support for multiple languages, an increasingly important consi derati on as very 
different languages, such as parallel languages, are created. 

7. 2 Riture Work 

Rcause Mygen presents afeasible solutionfar provi ding debugging support, it is interest- 
ing to speculate upon vhat directions further research in the area of debugger generation 
right take. 



CHAP TER 7 . CONCL US I ONS 



55 



IbLe 7. 1: Future Maygen Wjrk 



AkEtional test sets 

Improved test cases 

financed skel eton and addi ti anal i nterf ace routi nes 



7. 2. 1 IVftygen Prototype Enhancements 

Several areas call for imacEate inprovemnt inthe Mygenprototype. Mst notablyis the 
need to further explore the sample space of progrannfang languages and their evaluation 
ermronmnts by creating additional test sets. Agoodthirdtest set right be the Ii sp[ M84, 
&o86] language along viththe lisp runtim system In addi ti on, the existing test cases 
shouldbe expanded vhere possible inorder toproduce debuggers wthincreasedamuntsof 
functionality. Bnally, the existing debugger skeleton could be enhanced to provide a greater 
mxim! arnunt of supported generated debugger functionality. This enhancemnt vould 
mst likely also require the specification of additional interface routines to be provided by 
the language and/or architecture developers. The suggested irmadi ate mcEfications to 
the Mygen prototype are sunnHrizedin "Hie 7. 1. 



7. 2. 2 Rel ated Areas to Expl ore 

This section presents research areas suggested by Mygen vork but of a inch broader na- 
ture than that presented in the previous section These areas can be grouped into f our 
pri nary topics: creation of a Rmtim Systemlnterface (ESI); dicmrterizaticnd a Ian 
guage, architecture, or runtim systemand the subsequent automtic generation of the 
respective Interface routines fromeach characterization; debugging of optimzed code; and 
true debugging of parallel system. 

The division of the "weld' that Mygen debuggers viewis a rather unique one. A- 
thoughthe separation of a source programfromthat onvhichit runs, its evaluationenvi- 
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ronmnt, is a viable approachfor the Mygen debugger, an alternative cE vi si on right be 

to separate the source programfromits runtim systemas veil as fromits architecture. 1 

This approachright provide for a "cleaner" and mre trad tional cE vision; but, at the s ana 

tina, this approach right be unnecessarily conpl ex due to the desire to exploit higher- level 

abstractions vhen available, as described in Section 4. 2. 

Amre thought-provoking area to explore is that of characterizing a source language 
in a vay that a generation systemcould then autoiBtically create the Source language 
Interface routines defined in the Mygen system Analogously, the characterizations of 
a nachine architecture and of a runtim system as veil as the subsequent generation 
of Mchine Achitecture Interface andRmtim Systemlnterface routines pose interesting 
questions. Akey idea to keep in rind, though, is that althDughanathodof characterization 
for these areas couldprove theareticallyinteresting, it right not be practical inthe context 
of effiient debugger generation Ibr exanple, language developers right findit mch easier 
to confarmto a set protocol for interface interaction (i.e. , provide defined routines) rather 
than to confarmto a "characterizationmthod" for describing their language (i.e. , provide 
a characterization of their language). 

Athirdideais that perhaps a debugger generation systemcould be developed that can 
better handle the debugging of optimzedcode. Astart inthat directionis that generated 
debuggers right be able to support senariically-unchargingor^iiizaticns-eptirizations 
that are transparent to the user, such as dealing vith register use versus namry use or 
caching. Another exanple of suchanoptimzationvouldbe one that naves a value to a 
storage place earlier than expected according to the source program, but that does not nat- 
ter since that particular namry location is not needed any mre. lirmessy exarines the 
tradeoff betveen the optimzationaf code and the ability to symolically debug it[Iin79] , 
vfrile Zellveger both studies the prohlemaf debugging optimzed program and attemts 
to confront one aspect of this prohlen[i&184] . 

Anna! area of research suggested by Mygen vork is the generation of true parallel 



"Achitecture" in this case refers to the evaluati on environiKnt rinus the runtiiK system 
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IbLe 7.2: Debugger Generati on Systems: Ar e a s to Ex p l o re 



Separati an of runtimsysterrinterface 
Characterization of source languages 
Gnerati on of SEE routines 
Characterization of mcbine architectures 
Gnerati on of MI routines 
Characterization of runtim system 
Gnerati on of ESI routines 
Holding of Cptimzed Code 
AkEtianof Tue Rjrallelism 



debuggers. Athough Mygen' s approach of having knovl edge of mltiple processing nodes 

but debugging only one node at a tim is suffiient for this initial project in debugger 

generation, future wrkwll probably need to better address parallel debugging issues. 

The suggested areas to explore in further research of debugger generati on system are 
surmrizedinlible 7.2. 

Whout question, Mygen not only has presented an interesting and viable approach 
to providing debugging support for nitiple language system, but has also suggested a 
veal th of interesting research topics to pursue. 
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SLI Input File Tfenplate 



%% INPUTniEPORMrKIlSaHEL^GlMi; 

saKEL/mxEwm 
(e.g., ai) 

your sourcel anguage nam 

QBinffiaHM PAH 

(e.g., /users/tsien/mygen/opal /) 

w##% 

your debugger 1 i br ar y_pat h _nam 

IIHniRnffi«a A niEffl\EWITHIirLD«IN3"lib" CRTrWIIN3".a" 
(e.g., for "libmf_debug.a", only use "mf _debug") 

w##% 

your 1 i br ar yfil enaiK 



Wo 
mftocedures: Wo 
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i. m##%y 

int initsli (vo i d) 



/$atfequires: 

modifies: 

/^Effects: Ebes any necessary i nit i aliz at ions for SII 
°/% Ifeturns: li f everything initi ali zed ok; otherwise. 
/$oN)te: (If procedure rissing, assunad that there is 

°/% no initi alizati on necessary f o r SII) 



2. W##%[Yor f] 

int napoc_to_object(char *proc, char *label) 

m = 

/$atfequires: proc is nana user uses to refer to given procedure 
°/% label is nana that conpiler right use to refer to proc 

modifies: 

mHfects: 

°/% Ifeturns: — 1 i f syntax error in proc spec 40 

°/% i f procedure not found 

°/% n > 0, where n =obj ect line corresponding to 

°/% the source code of proc 



3. ^t##%[Yor f] 

int na||j , ocbegin_to_object(c h a r *proc, char *label) 

m = 

/$atfequires: proc is nana user uses to refer to given procedure 
°/% label is nana that conpiler right use to refer to proc 

modifies: 

mHfects: 

°/% Ifeturns: — 1 i f syntax error in proc spec 

°/% i f procedure not found 

°/% n >0, where n =obj ect line corresponding to 

°/% the beginning source line of proc 
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4. ^t##%[Yor 1} 

i n t rffljj , ocend_to_object(c h a r *proc, char *label) 

m = 

/$atfequires: proc is nam user uses to refer to given procedure 
°/% label is nana that conpiler right use to refer to proc 

modifies: 

mHfects: 

°/% Ifeturns: — 1 i f syntax error in proc spec 

°/% i f procedure not found 

°/% n, where n =object line corresponding to 

°/% the end source line of proc 

Wb 7 

5. ^t##%[Yor f] 

void trpi»cedure(c h a r *proc, char *label) 

m = 

/$atfequires: proc is nana user uses to refer to given procedure 
°/% label is nam that conpiler uses to refer to proc 

modifies: 

/^oEfiects: Ebes whatever is necessary to trace proc 

Wo Ifeturns: 

Wb 8 

6. ^t##%[Yor f] 

i nt naspDurcetoobj ect(i nt srcline) 

w, = 

/$atfequires: srcline is an integer 

mMdifies: 

mHfects: 

Wb Ifeturns: —1 i f there is not source code at line srcline, or 

Wb i f a breakpoint cannot be set at that line. 

Wb n, where n =obj ect line corresponding to 

Wb line srcline. 
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7. m##%y 

i n t reay4ibols(c h a r *filenam) 



/^olfequi res: fll enam i s the nam of fil e vi th synbol s to be read i n 

modifies: 

'WoWkcts: Loads user programsynbols and/ or labels; 

Wo sets global i n t programtartloc to be address of 

Wo where programstarts, i f knowi. Sets global 

Wo char useprogranf] to be fll enam. 

Wo Ifeturns: li f synbol s read successfully; otherwise. 



8. ^t##%[Yor 1} 

void prliaibels(c h a r *argl) 



/$o!fequires: argl is not required, but could be used 

modifies: 110 

/$oEnects: Prints out labels of user programcurrently loaded. 

Wo Ifeturns: 



9. ^t##%[Yor ^ 

void j)refcedures(c h a r *argl) 



/^olfequires: argl is not required, but could be used 

modifies: 

/$oEnects: Prints out procedures of user programcurrently loaded. 120 

Wo Ifeturns: 



10. ^t##%[Yor ^ 

void prayirbols(c h a r *argl) 
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/^olfequires: argl is not required, but could be used 

modifies: 

/^Effects: Prints out synbols of user programcurrently loaded. 

Wo Ifeturns: 130 



11. ^t##%[Yor 1} 

void disriiayrce_line_text(c h a r ;5sirne) 

w, = 

/^olfequires: src line is a line of user programor is enpty 

mMdifies: 

/$oEnects: Hints out source code corresponding to line src line 
Wo of user program or, i f srcline is enpty, then 
Wo shows current 1 ocation i n programand the source 
Wo code corresponding to current location. 
Wo Ifeturns: 



12. ^t##%[Yor 1} 

void untrjac©cedure(c h a r *proc, char *label) 

Wo = 

/^olfequires: proc is nam user uses to refer to given procedure 

Wo label is nam that conpiler uses to refer to proc 

modifies: 150 

/$oEnects: Ebes whatever is necessary to untrace proc 

Wo Ifeturns: 



13. ^t##%[Yor 1} 
void pralritinfo(v o i d 



9%Ifequires: 

mMdifies: 

/$oEnects: print source language infornati on relevant to debugging 

Wo Ifeturns: 
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14. ^t##%[Yor ^ 

i n t ftocessSIIA , gs(i n t argc, char *argv[] , c h a r *prognam) 



/$oFequires: prognam is nam of debugger program 

modifies: 

/^Effects: Processes argumnts, i f any, of a generated debugger. 

°/% Prints a "Usage error:" line to output i f returning 0. 170 

°/% Feturns: li f everything ok; otherwise. 



EXTE^IWdMfflNEB 



NJ\HR(T EXIE^I CNOMMS 

(0 <=nunber <=20) 

( m##% 180 

<tmnber> 

For each extension conmnd, specify: 

(1) helpline, including both nam of comaxid user w 1 1 type 

and hel p stri ng f o r hel p mnu 

(e.g., "ta Toggle all-solutions.") 

(2) invocation of nam of routine to be called, using argumnts 

argl, arg2, arg3 (rax 3 args) 

(e. g. , "toggle_all_solutions() ;") 

(3) ext e r n reference line 190 

(e.g., "extern void toggle_all_solutions () ; ") 

EXStfEE 

Extension Conmnd 1 
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ta <i> Toggle all —solutions, n =nax nunber of solns 

toggl eallsol uti ons(argl) ; 

( m##% 200 

extern vo i _sdljboggltfeons(); 



Ap p e n d i x B 



MAI Input File Tfenplate 



m INOTHIEKIMrKHTWIIMHTKIUE 

TMET^KH TKIUE ME 

(e.g., CM) 

w##% 

your archi tecturenam 

hhiiir u mm pah 

(e.g., /users/tsi en/imygen/orn / ) 

your debugger 1 i br ar y_pat h _nam 

IIHnHinffii«^niEffl\EWmiirLD«IN3"lib" CR r IrWIIN3".a" 
(e.g., for "libmf_debug.a", only use "mf _debug") 

w##% 

your 1 i br ar yfil enam 

ACiraLMJ\ffiRCFPKnSSIN3MIIS INTKET^EfflTKlUE 
("1" for a uniprocessor) 

w##% 

your nunber 
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HSIHDNJ\ffiR(THaiSSIN3N3IS INTMEMfflTKIUE 
(HSIHDMJ\ffiR<=A3raLMJ\ffiIi "1" for a uniprocessor) 

your nunber 



Wo 
mftocedures: Wo 



i. m##%y 

i n t iniit(v o i d 



/^olfequires: 

mMdifies: 

/^oEfiect s : Ebes any necessary initi alizations for MI 

Wo Ifeturns: li f ini ti alizati on successful ; otherwise. 



2. m##%y 

i n t progralmaded(v o i d 



/^olfequires: 

modifies: 

mHFects: 

Wo Ifeturns: 1 i f programis loaded 

Wo i f programis not loaded 



3. ^t##%[Yor 1} 

i nt Install MchineB'eakpoint(i nt addr) 

Wo 

9%Ifequires: addr is a valid code address of the current 

Wo programwhere a breakpoint can be set 

/$oMidi fies : (object code) 



40 
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/$oBfects: Installs a breakpoint at addr such that when 

Wo programexecuti on reaches addr, it halts 

Wo Ifeturns: Qiginal instruction (i nt ) being repl aced by breakpoint, 

Wo to be passed to Uiinstall MchineBeakpoint. Ifeturns 60 

Wo an integer <0 i f did not install correctly. 



4. m##%y 

void contijmegran|iv o i d 



/^olfequires: 

mMdifies: 

9%Enects: If programis running, continues running it. 

Wo Qhervise prints a mssage to user that program 70 

Wo should be started first. 

Wo Ifeturns: 



5. ^t##%[Yor 1} 

i nt Uiinstall MchineBeakpoint(i nt addr, i nitetjrm<gtion) 

w, = 

/^olfequires: addr is avalidcode address of the current 

Wo programwhere a breakpoint can be remwed; 

Wo orig instruction is identical to that returned by 80 

Wo Inst all MchineBeakpoint 

/$oM>di fies : (object code) 

/$oEflects: Uiinstalls a breakpoint at addr such that when 

Wo programexecuti on reaches addr, it no longer halts 

Wo due to this breakpoint. Qiginal instruction is 

Wo reinstated. 

Wo Ifeturns: i nt n: n=6 i f worked correctly; n<£) i f did not work 



6. ^t##%[Yor 1} 

i n t SetMchineftocBeakpoint(c h a r *proc, i n t n, i _aa)t trace 
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/^oFfequires: proc is nam user uses to refer to a procedure on which 

Wo a breakpoint is to be added 

Wo nis the code address where this procedure starts 

/$oMidi fies : (object code) 

/^oERects: Aids proc to list of procedure breakpoints by calling 

Wo i nt addtoprocbreakpt _list(c ha r *proc, i nt addr, 

Wo i nt tracen). (1 i f good; Oi f bad) 

Wo (in SKEL) and adds corresponding nachine address 

Wo breakpoint (s) fromlist by calling (in SHL ) 

Wo i nt addtomchine breakpt list (i nt addr). 

Wo (li f good; Oi f bad) 

Wo Ffeturns: li f set successfully; otherwise 



7. ^t##%[Yor 1} 

i n t GearMchineFrocEreakpoin^c h a r *proc, i n t n) 

Wo = 

9%Fequires: proc is nam user uses to refer to a procedure on which 110 

Wo there is a breakpoint to be rerroved. 

Wo nis the code address where the procedure starts 

/$oMidi fies : (object code) 

z^oEffect s : Fferroves proc fromlist of procedure breakpoints by calling 

Wo i n t rerrovefromproc breakpt _list(c h a r *proc, i n t addr) 

Wo (1 i f good; Oi f bad returned) 

Wo (in SHL) and remves corresponding nachine address 

Wo breakpoints fromlist by calling (in SHL ) 

Wo i nt rem>ve_from_mchine breakpt list (i nt addr) 

Wo (1 i f good; Oi f bad returned) 

Wo Ffeturns: li f successful; otherwise 



8 . m##%y 

i n t repEDgranlLC h a r *nlenam) 
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/$atfequires: fllenam is the nam of file to be read in 

/^oMdi fies : (rachine state) 

/^oEnects: Loads user program loads the code into the code 

Wo mirory. Set flags such that program loadedQ w 1 1 

Wo r e t ur n true. Ifeinitialize mrrory, etc. 

Wo Ifeturns: fi f programread successfully, otherwise 



9. ^t##%[Yor f] 

void pri agister content s(c h a r *argl, char *arg2) 

w, = 

/$atfequires: argl is possibly anenvironmnt 

mMdifies: 

/^Effects: Hints the contents of the rachine registers; 
Wo If envis given, only prints that environmnt 
Wo Ifeturns: 



io. m##%y 

void _pm>gran|ic h a r *al) 

m = 

/$atfequires: argl is enpty or is a li ne nunber at vbi ch to begj n 
Wo execut i on 

modifies: 150 

9%Enects: Ifeports that user programis already running (and 
Wo suspended) or e lse begins to run the program 
Wo Ifeturns: 



11. ^t##%[Yor 1} 

v o i d_sdep(c h a r *argl, char *arg2) 

Wo = 

/$atfequires: argl is enpty or the nunber of steps user wants to step. 

Wo arg2 is enpty or the location fromwhich to begin steppi ng 

modifies: 
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/^oEftect s : Executes argl steps of user progranj beginning at 
°/% location arg2. 
9%Ffeturns: 



12. ?###%[ Yor f] 

v o i d_bi(g_step(c h a r *argl) 



/$oFfequires: argl is enpty or the location fromwhich to begin stepping 170 

modifies: 

/^oEftect s : Executes a process/procedure of user progranj beginning at 
°/% location argl. 
9%Ffeturns: 



is. m##%y 

void rasKthine(v o i d 



/$oFequires: 180 

9%Mdifies: rachine state 

/$oEnects: Ffesets the rachine state, sets running to false (0) 



14. ^t##%[Yor ^ 
void priarit _info(v o i d 



/$oFfequires: 

mMdifies: 

/$oEnects: Prints out inf or rat ion about user progranj debugger 190 

°/% status, etc. 
9%Ffeturns: 



15. ^t##%[Yor f^ 

i n t FrocessM[A , gs(i n t argc, char *argv[] , c h a r *prognam) 
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/$oFequires: prognam is nam of debugger program 

modifies: 

/^Effects: Processes argumnts, i f any, of a generated debugger. 200 

Wo Prints a "Usage error:" line to output i f returning 0. 

Wo Feturns: li f everything ok; otherwise. 



16. ^t##%[Yor f] 

i n t changDde(i n t argl) 



/$oFequires: argl is aninteger specifying the newnode to be 

Wo debugged Is al ready checked for <=nax avai 1 abl e 

Wo and >0 

9%Mdi ties : nachine state 

/$oEnects: Ebes the necessary internal state changes to debug 

Wo node nunber argl 

Wo Feturns: li f everything ok; otherwise. 



17. ^t##%[Yor 1} 

i n t reshaaber nodes (i n t argl) 



/$oFequires: argl is aninteger specifying the newdesi red nunber 220 

Wo of processing nodes. Is already checked f o r <=nax 

Wo and >0 

/^oMdi fies : nachine state 

/$oEflects: Ebes the necessary internal state changes to alter 

Wo desired nunber of nodes available to argl 

Wo Feturns: li f everything ok; otherwise. 



EXE^IWOMINS 230 
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NJ\ffiR(T FKMUl (JJOIKB 
(0 <=nunber <=20) 

W##% 
<nunber> 

R>r each extension conmnd, specify: 

(1) helpline, including both nam of conrand user w 1 1 type 

and hel p stri ng f o r hel p mnu 

(e.g., "ta Toggle all-solutions.") 

(2) invocation of nans of routine to be called, using argunsnts 

argl, arg2, arg3 (nax 3 args) 

(e. g. , "toggle_all_solutions() ;") 

(3) extern reference line 

(e.g., "extern void toggle_all_solutions() ; ") 

EXMtE 

Extension Conmnd 1 

ta <Jr> T)ggle all —solutions, n =nax nunber of solns 

toggl eallsol uti ons(argl) ; 

extern vo i _sdljboggltfeons(); 



Ap p e n d i x C 

Sanpl e OMVi r t ual Mchi ne Mff 
I nput Fi 1 e 



m MI INOTHIEKItT«IIMHTraUE(MVIBraLJ\«HKE 

TKEMfflTKlUEME 

(M 

hhiiir u mm pah 

/users/tsi en/imygen/on/ 

IIHnHlUmAE6 A niEffl\EWlHliriEDN3"lib" CRTRMnN3".a" 
ng mi 
AdraLMJ\ffiR(TPKnSSIN3MIIS INTKET^EfflTKlUE 

1 



10 
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HSIHDNJ\ffiR(THaiSSIN3N3IS INTMEMfflTKIUE 

i 



/^ftocedure 



(7o 

i. m##%y 

i n t imit(v o i d ) 

2. W##%Y 

i n t progralmaded(v o i d ) 

i nt InstallMchineB'eakpoint(i nt addr) 

void contijmegranliv o i d ) 

5 . <m##%y 

i nt liinstallMchineB'eakpoint(i nt addr, i nitastarmigfion) 

4 

6 . <m##%y 

i n t SetMcrdneH , ocB , eakpoint(c h a r *proc, i n t n, i_cm)t trace 

7. <m##%y 

i n t GearMchineFrocBeakpoin^c h a r *proc, i n t n) 

8 . <m##%y 

i n t repcbgranlLC h a r *filenam) 

9. ^t##%Y 50 

void pri agister content s(c h a r *argl, char *arg2) 

io. ( m##%y 
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void jprogranlic h a r *al) 

11. m##%y 

v o i d_sdlep(c h a r *argl, char *arg2) 

12. m##%y 

v o i d_bfl<g_step(c h a r *argl) 60 

is. m##%y 

void reaaKthine(v o i d ) 

14. ( m##%y 

void priaat _info(v o i d ) 

is. ( m##%y 

i n t ftocessM[A , gs(i n t argc, char *argv[] , c h a r *prognam) 

70 

16. 9^t##%N 

i n t changede(i n t argl) 

17. 9^t##%N 

i n t reshaaber nodes (i n t argl) 



EOE^IWCaraNEB 
NJ\ffiR(T FKMUl OVCQMNEB 

12 

Extension Conrauid 1 

ta Toggle all —solutions. 

t oggl e_al l_s ol ut i ons ( ) ; 
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extern vo i _dljfcogg]teons(); 90 



Extensi on Cornmnd 2 

tb Toggle breadth— first search. 

toggl ebreadth first () ; 

extern vo i lie adg^ (first (); 



Extensi on Cornmnd 3 

tq Toggle quiet rnide. 

toggl e_qui et_m>de() ; 

extern voi cjlii ifeogglid 



Extensi on Cornmnd 4 

tp Toggle process trace. 

t oggl e_pr oces s _t r ace ( ) ; 

extern vo i _jiofcegglterace(); 



Extension Cornmnd 5 120 



ti Toggle instruction trace. 
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toggl e_i nstructi ontraceQ ; 
extern vo i ihstDgglfeontraceQ; 



Bdensi on Ghrnmnd 6 

( m##% 130 

td Toggle synbolic reg display, 

toggl esynbolic displ ay(); 
extern vo i _s| r ntoggfce_di s pl ay(); 



Bdensi on Coimauid 7 

pc ftint code from<h>to <JiJ> 

print_code(argl, arg2); 

extern vo icsile^jnt 



Bdensi on Conrnnd 8 

ph ftint heap from<ti>to <ji> 

printheap(argl, arg2); 

extern vo iliApjp^int 



Bdensi on Conrnnd 9 

pm ftint mssage ( det ai 1 ed cont ent s of Mreg 
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printnsssage _info(argl, arg2); 160 

extern vo i_rrisf^fentinfo(); 



Extension Ghrnmnd 10 

pp ftint process ( det ai 1 ed cont ent s of Preg). 

print_process_info(argl, arg2); 

( m##% 170 

extern vo iprf)CfKsritnfo(); 



Extension Cornmnd 11 

pq Print nsssage queue. 

pri ntqueue cont ent s ( ) ; 

extern vo ^qitufrimtntentsQ; 



Extension Cornmnd 12 

pt ftint process tree. 

pri nt_process_tree() ; 

extern vo iprf)Cfssnltree(); 
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